home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / osids / osids-minutes-92jul.txt < prev    next >
Text File  |  1993-02-17  |  23KB  |  575 lines

  1. Editor's Note: Minutes received 8/12
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5. Reported by Steve Hardcastle-Kille/UCL, Doug Simmons/IBM and Justin
  6. Walker/Apple
  7.  
  8. Minutes of the OSI Directory Services Working Group (OSIDS)
  9.  
  10. Comments on Agenda
  11.  
  12. Mark Knopper sent apologies for non-attendance and then turned up.
  13.  
  14. Here follow comments on the Minutes from San Diego (OSI-DS-MINUTES 7),
  15. particularly relating to action items from that meeting:
  16.  
  17.  
  18.    o Regarding maintenance of RFC-1274, it is Steve and Paul Barker who
  19.      will be involved, not Colin as the Minutes claimed.
  20.  
  21.    o Eric Huizer's strategy document is ready (comments will be made
  22.      later in the Minutes).
  23.  
  24.    o Chris's documents (OSI-DS 14, 16, 17, 19) have not been revised.
  25.      This will be done by the next meeting.  Mark Knopper has taken up
  26.      the network schema.
  27.  
  28.    o Documents OSI-DS-12, 23, 24 have been revised and submitted to the
  29.      IESG. As suggested in the previous meeting, Steve Hardcastle-Kille
  30.      read NADF 175 (which has been revised to NADF-(***Didn't get the
  31.      reference***).  He cleared up some misconceptions regarding he NADF
  32.      position, but overall, his position did not change from the last
  33.      meeting.
  34.  
  35.    o Wengyik continued to work on interoperability issues.  However, he
  36.      had no input, since he was not present.
  37.  
  38.    o There will be a NADF meeting next week (that is, the week of 7/20).
  39.  
  40.    o The QOS experiments will be discussed as indicated in the Agenda.
  41.  
  42.    o The JPEG schema was reviewed.  However, the Schema group had not
  43.      yet formed, so this item was continued.  Paul Barker was to
  44.      establish the schema group, but this had not done this because of
  45.      overload due to Steve's departure to the ISODE Consortium.
  46.      Resources were requested (volunteers were solicited; no response
  47.      was heard from Russ and Mark).
  48.  
  49.    o The Character Set experiment wasn't discussed because Geir Pederson
  50.      wasn't present.  The action was continued.
  51.  
  52.    o Tim Howes brought us up to date on the DIT Counting effort.  The
  53.      code has been written, and will appear in the next ISODE Consortium
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61.      release of QUIPU. The item was continued.
  62.  
  63.    o Work on schema publishing was completed and will be discussed
  64.      later.
  65.  
  66.    o The action item on preferred names was continued (no one was
  67.      present to speak on the subject).
  68.  
  69.    o Steve H-K finished the revision of RFC-1279 , with Wengyik
  70.      consulting.  The paper has not actually been updated (in its
  71.      electronic form).  It will be circulated.
  72.  
  73.    o The lightweight protocol note (LDAP) was revised and circulated.
  74.  
  75.    o Steve Hardcastle-Kille looked into possible ISO alternatives to SOS
  76.      (the Simple OSI Stack).  There are no current ISO proposals
  77.      addressing the SOS issues, but John Day (from BBN) has circulated a
  78.      document (in OSI circles) on the OSI upper layers.  Reviews are not
  79.      complete, but this document does not seem to be an answer.
  80.  
  81.  
  82. There were no Matters Arising.  We therefore moved right into the
  83. liaison reports.
  84.  
  85.  
  86.   1. RARE (Eric Huizer)
  87.      As reported at the last meeting, WG3 is no more.  The new RARE
  88.      structure has eight Working Groups, of which one, WGNAP (the
  89.      Working Group for Network Application support), will undertake
  90.      directory services (as well as time protocols, etc.).  A major
  91.      problem is that, while a Chair has been identified and wants to
  92.      undertake the work, he can't get permission to do the job.  WGNAP
  93.      hopes to meet in November.  A distribution list has been set up for
  94.      other than directory service issues.  WGNAP will continue to use
  95.      OSI-DS for its directory service discussions.  The Working Group
  96.      has small budget from RARE, provided they can come up with a
  97.      priority list of tasks.  This could be applied to travel.
  98.  
  99.   2. OSI/CCITT (Ken Rossen)
  100.      There were two significant events to report.  ISO 9594 passed to
  101.      DIS. The most significant change was in the area of access control
  102.      (replication and an extended information model).  DISP (shadow);
  103.      DOP (binding) are new protocols.  An access control context is a
  104.      combination of levels of access control.  The US pushed
  105.      successfully for simplified access control:  this only allows a
  106.      decision to be made at administration points (new in model); a
  107.      decision isn't overridden by lower levels of the tree.  As of the
  108.      last editing meeting, merged text was produced.  Unfortunately, the
  109.      circulated stuff was a mess.  There is a good copy, dated 12/25/91
  110.      (hence it is called ``the Christmas text'').
  111.      The second event occurred in May.  When ISO SC21 met in Ottawa, the
  112.  
  113.                                    2
  114.  
  115.  
  116.  
  117.  
  118.  
  119.    Directory Services Group also met, and changes to the Standard were
  120.    discussed (with a 2 year target, down from the usual 4).  Use of
  121.    OSI management (CMIP) to manage the directory was put on hold,
  122.    since the responsible party (from the US) resigned.  Work on
  123.    authentication could be undertaken as there is support for small
  124.    changes, e.g., certificate revocation.  This will wait for the next
  125.    meeting to commit effort to this work.  There was a feeling that
  126.    there is need for closer work with (ISO) security folks for a more
  127.    sophisticated security model.  Given upper layer security services,
  128.    there is a need for a scheme to apply to directory services.  Also,
  129.    there is a new edition of ASN-1 encoding rules, which could effect
  130.    directory.  Distinguished encoding rules were introduced that are
  131.    different from those currently used by the directory.  There is
  132.    need to work out conflicts.  This could affect digital signatures.
  133.    The 1992 X.500/9594 should progress at the next editing meeting in
  134.    Orlando, in the fall of `92 (this will involve serious cleanup.
  135.    Rows of ducks will be set up at a US meeting in Nashua this week.).
  136.  
  137. 3. OIW (Russ Wright)
  138.    The OIW continued work on standardized profiles for DAP, replacing
  139.    agreements from the OIW and EWOS. They are on schedule for results
  140.    by the end of year.  A joint meeting was held with the X400 SIG to
  141.    look at MHS and the directory.  Their desires right now are
  142.    unclear, but they will provide a clearer specification.
  143.    The IGOSS document was reviewed.  This is a combined document
  144.    representing input from GOSIP, the power industry, and the
  145.    manufacturing industry.  This requires `92 directory extensions,
  146.    including replication.  They were asked to review POSIX documents
  147.    relating to directory services.  The documents themselves are in
  148.    the mail.
  149.  
  150. 4. DISI (Chris Weider)
  151.    Documents describing advanced directory usage and how to get
  152.    registered in the directory have been worked on, but not
  153.    circulated.  A revision RFC-1292 has been worked on Four new papers
  154.    have been prepared:  a pilot catalog, a description of DIT setup,
  155.    the directory naming philosophy, and a schema for restaurant
  156.    information.
  157.  
  158. 5. AARN Mark Prior
  159.    There is not much happening at this time.  AARN is not willing to
  160.    commit to further work, nor are they willing to say no to further
  161.    work.  They are waiting for December (***Why?***).  There are
  162.    currently 40000 entries in their directory, and they have just
  163.    added affiliates.  Master and slave machines will be soon be
  164.    upgraded.
  165.  
  166. 6. NADF (Marshall Rose/Einar Stefferud)
  167.    The last NADF meeting was in April, the next will be next week
  168.    (7/20).  Discussion of vendor plans at the last meeting was
  169.  
  170.                                  3
  171.  
  172.  
  173.  
  174.  
  175.  
  176.      exciting (depressing?).  Several documents are available.  One
  177.      provides a naming scheme for a country (discussing principles), and
  178.      a second provides an application of these principles to the US. A
  179.      third discusses the theory and practicality of directory security.
  180.      This latter is up for more debate.  There is a desire for simple
  181.      authentication, but this may be difficult to protect from replay
  182.      attack.  The recommendation may be for protected passwords.  The
  183.      documents should become RFCs (but some can't even seem to be put
  184.      into the politically *in*correct PostScript format).  Marshall will
  185.      provide copies for Steve Hardcastle-Kille.  None of the twelve
  186.      vendors present supported any but simple authentication.  None
  187.      would commit to supporting `92 extensions (except one who was
  188.      planning to support the extended information model).  In short,
  189.      things don't seem to be going very well (according to public
  190.      comment at the meeting.  This is born out by Ken's observations at
  191.      COS). There seems to be more positive support for simplified access
  192.      control (over the basic version).
  193.      Ken noted that they think they've fixed NADF complaints.  Time was
  194.      spent at the Ottawa meeting on defect resolution (there is a
  195.      directory implementor's guide; see Ken).  There seems to be some
  196.      interplay between ISO, NADF.
  197.  
  198.  
  199. As no pilot project representatives were present, we continued on with
  200. the rest of the Agenda.
  201.  
  202. The Naming Guidelines Document, the UFN Document, and the Document
  203. Defining String Representation of UFN's.  All three were submitted in
  204. April to the IESG. They are expected to move forward by end of this
  205. month.
  206.  
  207. The Strategy Document.  The Strategy document (based on Steve's
  208. original) was much modified, based on comments received.  Most of the
  209. original was retained, but with editing and restructuring.  One of the
  210. main criticisms was references to other RFCs without indicating the RFC
  211. content.  Eric's solution was to pull the main points from the RFCs in
  212. question, using reference only for detail.  He added deployment details
  213. and requirements.  Therefore, there were a lot of references to DISI
  214. papers.  The ASCII version (as posted) was quite unreadable.  Apologies
  215. were tendered, along with a promise to fix it.  Comments were requested.
  216.  
  217. One comment at the meeting:  a possible extension involving the use of
  218. large data values was questioned.  The response was that this is only a
  219. *possible* extension, not a planned (or required) one.  An observation
  220. was made that all items in this section (of the document) could be
  221. termed controversial.  The main point is that the model is not rigid:
  222. if deployment experience indicates that a change is needed, it will be
  223. addressed.
  224.  
  225. Regarding progress to ID-hood for the strategy document, the approval of
  226. the other authors is needed.  Then an informational RFC can be
  227.  
  228.                                    4
  229.  
  230.  
  231.  
  232.  
  233.  
  234. submitted.  Steve Hardcastle-Kille wants to see this done reflecting an
  235. IAB/IESG consensus (as was done, e.g., for RFC-920).  He wants the
  236. submission and publication to reflect IAB policy.  It is unclear what
  237. the tradition is.  It was felt that we should have OSI-DS consensus, so
  238. a sense of meeting was taken; there were no votes against the document,
  239. but there were a large number of abstentions (from those who had not
  240. read it yet).  Eric will take changes, publish the new document as an
  241. RFC (both text and PS formats), and get it into the IESG stream.  The
  242. attendees seemed to favor not waiting for the next meeting, given the
  243. consensus here (all who had read approved).
  244.  
  245. Eric noted that none of the three documents mentioned earlier showed up
  246. on the IESG action list that he gets.  This was deemed to be a dropped
  247. ball.  Eric will follow up to determine how the ball got dropped and
  248. assure that it doesn't happen again.
  249.  
  250. Tim Howes:  Some comments on the schema document, from Colin Robins
  251. (sent by email to the OSI-DS list), were distributed.  Given that the
  252. schema is rapidly changing, the idea of storing (a description of) the
  253. schema in the DIT has been investigated.  Tim looked first at the '92
  254. Standard, which was very complicated.  The `92 information is in his
  255. document, but comments he's received indicate that it (the `92 content)
  256. should be pared down.  The document talks about representing attribute.
  257. information in the directory, although no syntaxes were defined.
  258. Although the document says this work will be a subset of `92, Tim
  259. doesn't think it really is.  We must decide on compatibility with `92
  260. vs.  having something ``now''.
  261.  
  262. The question was asked:  what are the areas of incompatibility?  Among
  263. others, there is the attribute syntax, which is difficult to figure out.
  264. From Colin:  how does one go from an OID to an identification of
  265. information it represents?
  266.  
  267. It was noted that an OID tree may be useful by itself, independent of
  268. other uses.  There is a bootstrap problem with this.  The issue is where
  269. to find a description of information, and what is the efficiency hit?
  270. Using well-known locations in the DIT may avoid a recursive upward walk
  271. of the tree.  This also assumes a configuration run that tells the DSA
  272. what well-known locations to check.  The directory doesn't do dynamic
  273. interpretations of OIDs.  It was observed that ``compatibility w.  92''
  274. and ``something that works'' may not be exclusive.  Two actions
  275. resulted.  The first was to define the OID tree.  The second was to
  276. revise the schema notes in light of the discussion.  Tim took both.
  277.  
  278. QOS Experiments.  There was no change from the previous meeting.  This
  279. work has not been a priority (although there is work ``scheduled'', to
  280. be done on Macintosh DUA). Sylvain noted that code that he has seen
  281. doesn't match the RFC (which may have changed since he last checked it).
  282. Tim wanted this taken off the Agenda, since it isn't a priority.  He
  283. would like to surprise us with progress when it happens.
  284.  
  285. JPEG. The JPEG attribute is not in the schema, but there is code to
  286.  
  287.  
  288.                                    5
  289.  
  290.  
  291.  
  292.  
  293.  
  294. handle it in ISODE. Russ would like this to be its end.  Proposed to
  295. carry over to next time when the schema group is represented (and so it
  296. shall be).
  297.  
  298. Character Set.  (Geir Pederson was not present):  Again, the schema
  299. group was an issue.  A discussion commenced on how to get this done.
  300. IANA was suggested as a source of help.  A problem with this is that we
  301. would need to find someone with directory experience to take on some
  302. editing load.  It was recommended that we talk with IANA, then worry
  303. about the short-term.
  304.  
  305. Selection of the time and place for the next meeting involved two
  306. choices:  INTEROP (October in San Francisco), and the next IETF
  307. (November in Washington).  A vote marginally favored the November IETF
  308. meeting, and this was agreed on.
  309.  
  310. DSA and DUA Metrics (OSI-DS33 ,OSI-DS 34)
  311.  
  312.  
  313.    o Measure pilot projects' success.
  314.  
  315.    o Deliverables - metrics papers for:
  316.  
  317.       -  DUAs.
  318.       -  DSAs.
  319.       -  Pilots' metrics.
  320.  
  321.  
  322.    o No absolute measure of goodness or badness of DUAs; there's SOME
  323.      importance to the numbers, though.
  324.      Comments on these papers:
  325.  
  326.    o Set up an FTP ID to keep the OSI-DS documents in for easy retrieval
  327.      before these meetings.  SEH to address.
  328.  
  329.    o DSA Document - need hands-on experience to tell if this document is
  330.      really worthwhile and accurate.  (comment by Eric Huizer).
  331.  
  332.    o DUA document - section l2 (query resolution) not very clear what
  333.      one should enter to initiate the query (comment by Time Howes).
  334.  
  335.    o DUA document - 5 steps to enter a query as opposed to on line via
  336.      UFN.
  337.  
  338.    o BOTH - is this a Consumer Reports on DUAs/DSAs?  SEH - the user
  339.      endorsement section contains the necessary feedback for analysis.
  340.  
  341.    o BOTH - there were comments from Paul Andre, were they being
  342.      incorporate?
  343.  
  344.  
  345.                                    6
  346.  
  347.  
  348.  
  349.  
  350.  
  351.    o DSA Document - section 5,need to discuss the environment - how can
  352.      we measure implementations on different machines?  (comment by Tim
  353.      Howes).
  354.  
  355.    o DSA Document - need more than lOO to 5OOO entries for accurate
  356.      testing (comment by Tim Howes).
  357.  
  358.    o DSA Document - need more discussion on security aspects (unknown).
  359.  
  360.    o BOTH - metrics will not be useful until they are tried out/tested
  361.      against (unknown).
  362.  
  363.    o BOTH - make measurements available via informational RFC.
  364.  
  365.    o DSA Document - other implementations tested besides QUIPU? (comment
  366.      by Sylvain Langlois) (Pissaro(sp?), ICL, Dirwiz....)
  367.  
  368.    o S. Hardcastle-kille:  How many of us are responsible for DUA
  369.      implementations?  Would it be worthwhile to make these documents
  370.      publicly available?  SEH to use RFC for informational test until
  371.      next meeting for feedbacks.
  372.  
  373.      E. Huizer             To do Siemens DSA.
  374.      T. Howes/R. Wright      Will do DUAs we'll evaluate findings at
  375.                            next meeting.
  376.      S. Hardcastle-Kille      To get these published as RFCs.
  377.      Everyone              To see that these get filled in when DUA's
  378.                            and DSA's tested.
  379.  
  380.  
  381.    o Comment - what's the difference between RFC 1292 and DS 33 and 34?
  382.      SEH: 33 and 34 much lower level (and more work to fill out) S.
  383.      Hardcastle-Kille suggested that the vendor be asked if they filled
  384.      out a 33 or 34 before answering to RFC l292.
  385.  
  386.  
  387. Representing Network Infrastructure Information in X.5OO (Mark Knopper)
  388. Draft circulated.
  389.  
  390. Soft Pages Project (Steve Hardcastle-Kille).
  391.  
  392.  
  393.    o Comment - IP name space:  defining an address hierarchy.  You
  394.      really don't need that, what advantage over a flat design?
  395.  
  396.    o Comment - Network elements diagram is a network topology.  What
  397.      happens if that changes?  (comment by Tim Howes).
  398.  
  399.    o Comment - (Mark Hopper).
  400.  
  401.                                    7
  402.  
  403.  
  404.  
  405.  
  406.  
  407.       -  Not sure if this resolves the problem.
  408.       -  It is too inefficient.
  409.       -  How do you get the bootstrap up and running?
  410.  
  411.  
  412.    o ACTION * - Mark Knopper to document how we might use this (where
  413.      might the holes be).
  414.  
  415.    o Comment - this tree can be kept small just by keeping the DSAs
  416.      ``near'' you in the DIT, as they are the only ones which should
  417.      interest you for cost purposes.
  418.  
  419.    o Comment - need FTP address for this document (FTP.TOHOKU.AC.JP).
  420.  
  421.    o Comment - do we need a Working Group to address this problem?
  422.  
  423.    o ACTION* Thomas Johansen and Mark Knopper to reconsider their
  424.      approaches and attempt some kind of convergence.
  425.  
  426.  
  427. LDAP (OSI-DS 26, OSI-DS 27)
  428.  
  429.  
  430.    o Comment - kerberos and simple authentication:  do we think this is
  431.      worthwhile and should it be added to the document before it becomes
  432.      an RFC? (Tim Howes).
  433.  
  434.    o S. Hardcastle-Kille:  Because it is implemented and deployed, then
  435.      it should be documented.
  436.  
  437.    o Comment - we should submit this to the Standards committee as soon
  438.      as possible.
  439.  
  440.    o Comment - suggestion that we have Christian look at it, as he has
  441.      strong views on the subject.
  442.  
  443.  
  444. DSA Naming (OSI-DS l3)
  445.  
  446.  
  447.    o Issue:  Avoiding Deadlock.
  448.  
  449.    o Comment - the DSA must be named higher in the tree (country level)
  450.      to prevent deadlock, but you do not insure uniqueness.
  451.  
  452.    o Comment - Erik seemed to remember opposition by the Pissaro group,
  453.      but could not elaborate.
  454.  
  455.    o Comment - using subtrees seems to be the way we fix things we can't
  456.      fix via X.5OO.
  457.  
  458.                                    8
  459.  
  460.  
  461.  
  462.  
  463.  
  464.    o ACTION* S. Hardcastle-Kille:  To re-write the paper to using
  465.      non-QUIPU language and references.
  466.  
  467.    o Comment - Erik not comfortable, seems like a way to fix a design
  468.      problem in QUIPU. Need input from other DSA vendors.
  469.  
  470.    o ACTION* S. Hardcastle-Kille:  To drop this as an OSIDS item and
  471.      take it up as a design issue with ISODE.
  472.  
  473.  
  474. Action Items
  475.  
  476.  
  477.  
  478. Chris Weider           Update OSI-DS 14, 16, 17, 19 (carried forward)
  479.  
  480. E. Huizer              Progress Naming Guidelines, DN Syntax, UFN, and
  481.                        LDAP and LDAP Syntaxes as RFCs.
  482.  
  483.                        Do Siemens DSA.
  484.  
  485. T. Howes/R. Wright      Will do DUAs we'll evaluate findings at next
  486.                        meeting.
  487.  
  488. S. Hardcastle-Kille      Get these published as RFCs.
  489.  
  490. Everyone               to see that these get filled in when DUA's and
  491.                        DSA's tested.
  492.  
  493. M. Knopper             To document how we might use this (where might
  494.                        the holes be).
  495.  
  496. T. Johansen/M. Knopper      Reconsider their approaches and attempt
  497.                        some kind of convergence.
  498.  
  499. S. Hardcastle-Kille      to re-write the paper to using non-QUIPU
  500.                        language and references.
  501.  
  502.                        Drop this as an OSI-DS item and take it up as a
  503.                        design issue with ISODE.
  504.  
  505.                        Revise Charter.
  506.  
  507. S. Hardcastle-Kille/E. Huizer      Discuss IANA support for Schema
  508.                        Management.
  509.  
  510. T. Howes               Write note on representation of OID Trees in
  511.                        Directory.
  512.  
  513. P. Barker              Publish Metric Papers as Internet Drafts.
  514.  
  515. S. Sataluri            Collect DUA survey results and publish as
  516.                        Internet Draft.
  517.  
  518.                                    9
  519.  
  520.  
  521.  
  522.  
  523.  
  524. Attendees
  525.  
  526. Ed Albrigo               ealbrigo@cos.com
  527. Claudio Allocchio        c.allocchio@elettra.trieste.it
  528. C. Allan Cargille        cargille@cs.wisc.edu
  529. Jodi-Ann Chu             jodi@uhunix.uhcc.hawaii.edu
  530. James Conklin            jbc@bitnic.educom.edu
  531. Robert Cooney            cooney@wnyose.nctsw.navy.mil
  532. Curtis Cox               ccox@wnyose.nctsw.navy.mil
  533. Urs Eppenberger          eppenberger@switch.ch
  534. Ray Freiwirth            5242391@mcimail.com
  535. Jisoo Geiter             geiter@gateway.mitre.org
  536. Arlene Getchell          getchell@nersc.gov
  537. Joan Goldstein           j_goldstein@tnpubs.enet.dec.com
  538. Steve Hardcastle-Kille   s.kille@isode.com
  539. John Hawthorne           johnh@tigger.rl.af.mil
  540. Tim Howes                Tim.Howes@umich.edu.
  541. Erik Huizer              huizer@surfnet.nl
  542. Takashi Ikemoto          tikemoto@xerox.com
  543. Kevin Jordan             kej@udev.cdc.com
  544. Jim Knowles              jknowles@trident.arc.nasa.gov
  545. Sylvain Langlois         Sylvain.Langlois@der.edf.fr
  546. Thomas Lenggenhager      lenggenhager@switch.ch
  547. John McKenna             mckenna@ralvm12.vnet.ibm.com
  548. John Murray              murray@premenos.sf.ca.us
  549. Mark Needleman           mhn@stubbs.ucop.edu
  550. William Nichols          nichols@wick.enet.dec.com
  551. Eric Nowak               nowak@ans.net
  552. Rakesh Patel             rapatel@hardees.rutgers.edu
  553. Mark Prior               mrp@itd.adelaide.edu.au
  554. Sheri Repucci            smr@merit.edu
  555. Jim Romaguera            romaguera@cosine-mhs.switch.ch
  556. Marshall Rose            mrose@dbc.mtview.ca.us
  557. Rich Rosenbaum           rosenbaum@lkg.dec.com
  558. Kenneth Rossen           kenr@isc.com
  559. Srinivas Sataluri        sri@qsun.att.com
  560. Douglas Simmons Mark Smithmcs@umich.edu
  561. Einar Stefferud          stef@nma.com
  562. Panos-Gavriil Tsigaridas tsigaridas@fokus.berlin.gmd.dbp.de
  563. Justin Walker            justin@apple.com
  564. William Warner           warner@ohio.gov
  565. Chris Weider             clw@merit.edu
  566. Brien Wheeler            blw@mitre.org
  567. Scott Williamson         scottw@nic.ddn.mil
  568. Steven Winnett           swinnett@bbn.com
  569. Russ Wright              wright@lbl.gov
  570. Yung-Chao Yu             yy@qsun.att.com
  571.  
  572.  
  573.  
  574.                                   10
  575.